home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 833 < prev    next >
Internet Message Format  |  1994-08-27  |  7KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: Gem List (corrected) (fwd)
  3. Date:     Sun, 17 Jul 1994 06:55:54 -0600
  4. Precedence: bulk
  5.  
  6. Hello Ken,
  7.  
  8. Please post from your own account, or sign-up the account you are posting
  9. from.  Would it really be that hard?
  10.  
  11. >Sounds like some of us enjoy re-inventing the wheel.
  12.  
  13. Some of us do, if the wheel was brain-dead to begin with...  :)
  14.  
  15. >> Warwick built GEM++ from scratch, so he did all the hard work.  Now if _I_
  16. >> use GEM++ for a dialog-in-a-window or something, it takes about 5 lines of
  17. >> code.
  18. >
  19. >Ooh, so I guess it's the *best* library out there from the way you speak?
  20.  
  21. GEM++ is very nice; I cannot speak for it from a programming aspect, but
  22. using it is very easy for the user.  From the comments of the various
  23. programmers, programming with GEM++ is simplicity itself, which is not
  24. true of most dialog libraries.  For example, as good as EGEM is, it is
  25. not easy to write a program using it unless you do so from scratch.  It
  26. expects your program to conform to a RIGID set of "features" (like
  27. absolute true non-modality).
  28.  
  29. >There. That was really difficult wasn't it? Now with the new window installed,
  30. >it WinLIB PRO handles the dialog, lets you move it, BACKGROUND click buttons
  31. >with the LEFT mouse button (and not some LAME left-right button simultaneous
  32. >click, I might add) and close it. WinLIB PRO handles everything for you when
  33. >you return a FALSE in the window dispatcher code.
  34.  
  35. Is this really important?  Three lines of code, five lines of code, who
  36. really cares?
  37.  
  38. >Gheez, like that's hard to code or something? So how do you set an
  39. >'active slider' in Gem++ without using special code (since you said you
  40. >don't write any special support code for it) and without doing anything
  41. >special to the RSC with a RSC editor (ooh mommy, changing the extended
  42. >object type is soooo hard!)
  43.  
  44. Does your sarcasm ever end?  I'm probably not alone in finding it
  45. annoying, and certainly misplaced.
  46.  
  47. >>From the consistent evasions of my questions, it's obvious you know nothing
  48. >about extended object types. (And yes, I fully expect you will dodge this
  49. >statement with yet more doublespeak).
  50.  
  51. Exactly what is it you want us to know about them (other than the fact that
  52. you have supperior knowledge of them).  I'll be the guinee pig, then.
  53. I know nothing of any importance about extended object types; I do not
  54. use them, and have no particular use for them.  Now what should I know?
  55.  
  56. >> I guess you've never compared the GUI code for an *application* using GEM++
  57. >> to that built with a "normal" library...
  58. >
  59. >That's true. Because there *ARE* no applications written using Gem++.
  60.  
  61. GEM NetHack, GEM GNU Chess.  If C++ ever becomes more popular on the
  62. Atari, I'm sure more people will use GEM++.
  63.  
  64. >> 1) They're afraid of GNU C/C++, since it's not a commercial product.
  65. >
  66. >Wrong. I have no problems with using PD compilers. The reason I stay away
  67. >from Gnu C/C++ is that I don't have the resources to waste (i.e. tons of RAM,
  68. >and tons of diskspace). And the fact that Gnu C++ spits out binaries roughly
  69. >5 to 20 times bigger than the *same code* in Pure C.
  70.  
  71. This figure is... <censored>.  Try, on average, less than 50%-60% larger.
  72. There are other public domain compilers, like SozobonX, that produce
  73. good object code.
  74.  
  75. >> 2) There's no commercial C++ implementation for the Atari.
  76. >
  77. >So?  The Atari's dead, anyway.
  78.  
  79. Well, there's a cheery thought, huh?  :)  So why -are- you here, exactly?
  80.  
  81. >--Ken Hollis (Bitgate Softwate)
  82.  
  83. >Background tasks are *meant* to be less responsive than the foreground
  84. >task. Otherwise there would be no distinction between the two. :-)
  85.  
  86. What on earth are you talking about?  Wasted CPU time is waster CPU
  87. time.  It has nothing to do with how responsive the background
  88. application is.  Wasted time affects performance, plain and simple.
  89.  
  90. >Better yet, break out a debugger and check things out for yourself. You DO
  91. >know how to use an assembler-level debugger do you not?
  92.  
  93. Maybe he does, but I do not.  That would require assembly language
  94. programming skills, which not everyone has (or needs).
  95.  
  96. >I've used MTOS enough to be disgusted with it. It's a piece of crap. Slow,
  97. >and inefficient.
  98.  
  99. Slow, inefficient, STANDARD.  People use it, and like it.  They may all
  100. have fast machines, but they are still using it.
  101.  
  102. >Our multitasking design *requires* that we have a 0ms timer event, since
  103. >we allow multiple threads of execution within one GEM program, even without
  104. >MultiTOS. You are free to use slower timer events, but your subthread
  105. >performance will suffer.
  106.  
  107. This sounds more complex that a dialog-library needs to be.  You mention
  108. that nobody uses GEM++, but will anyone use your library?  Not many people
  109. need threading, or the replaced AES functions that your library drags
  110. along with it.
  111.  
  112. >So, you're saying we NEED to watch for mouse rectangle events when our
  113. >application is not topped? That makes very little sense at all.
  114.  
  115. Why does this not make sense to you?  This discussion started with
  116. an argument over changing the mouse shape when it passes over a
  117. specific object type.  Why should your program stop doing this
  118. just because it is not the top application?  If the mouse passes over
  119. one of the object types in your dialog (even untopped) it should
  120. change shape.  If you do something, do it right and do it completely.
  121.  
  122. >Wrong. You do not "have" to do this. The slider in WinLIB PRO is defined by
  123. >its relation in the object tree to its parent object, and its extended object
  124. >type. There is *NO* reason whatsoever that you have to "attach" a child
  125. >object to its parent with some code to make it an active slider. In a good
  126. >library, this should be an inherent property from the structure of the RSC
  127. >file.
  128.  
  129. Umm, this may sound like a stupid question, but what about if the contents
  130. of your active slider CHANGES.  If you start with three items in your
  131. resource file, but suddenly need to put fifty in the active scroller,
  132. will that not cause problems?  What if you start with fifty and
  133. suddenly decide you only need three?  Do you just let the memory being
  134. used by the list go to waste?  I much prefer having to link a list of
  135. text items to the slider, since that way I can grow/shrink the list
  136. whenever I feel like it.
  137.  
  138. >The point is that whereas in WinLIB PRO, these changes can be made with a
  139. >RSC editor, whereas in Gem++ it requires code changes and recompilation.
  140.  
  141. If you change the resource structure, you will have to recompile your
  142. program no matter what, so this is not really a consideration unless
  143. the changes you are making are trivial (in which case you would not
  144. have to recompile no matter which library you use).
  145.  
  146. >Why bother designing a GnuC++ based library when only a tiny fraction of the
  147. >programmers out there can use it? That seems to me like cutting your own
  148. >throat.
  149.  
  150. Why bother designing WinLIB PRO and then insulting just about every
  151. programmer who would consider using it?  I cannot speak for Warwick,
  152. but I assume he wrote it because he wanted to use it, or he wanted
  153. to improve C++ for the Atari.
  154.  
  155. [You know, your messages in this digest were all posted twice...]
  156.  
  157.  
  158. -- 
  159. Michel Forget           \\   mforget@elfhaven.ersys.edmonton.ab.ca    //
  160. Electric Storm Software  \\  ess@tibalt.supernet.ab.ca               //
  161. PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F3 4A C6 A0 6E 02 71 85
  162.